A virtual machine (“VM”) is an abstraction (a “virtualization”) of a physical computer system. FIG. 1 shows an example of a virtualized computer system 700. A virtual machine 200 is installed on a host platform that includes system hardware 100. System hardware 100 includes one or more Central Processing Units (CPUs) 110, memory 130 (such as RAM (random access memory)), one or more hard disks 140 and various devices 170, such as Network Interface Cards (NICs), a keyboard, a display, etc.
VM 200 includes virtual system hardware 201 and guest software 203. Virtual system hardware includes one or more virtual CPUs 210, virtual memory 230, one or more virtual hard disks 240 and one or more virtual devices 270. Guest software 203 includes guest system software 202 and guest applications 260. Guest system software 202 includes a guest operating system (“guest OS”) 220 with drivers 224 for virtual devices 270. Virtual system hardware 201 is a virtualization of the underlying system hardware 100. In some virtualized computer systems, the virtual system hardware may have the same general architecture as the underlying physical system hardware, while, in other virtualized computer systems, the virtual system hardware may be a different hardware architecture from that of the physical system hardware. That is, the virtual hardware interface and resources visible to the guest system software 202 are mapped by the virtualization software onto the interface and resources of the system hardware 100. In some implementations, this mapping is invisible to the guest system software 202.
In implementations where the mapping is invisible to guest system software 202, guest system software 202 generally interfaces with virtual system hardware 201 in the same way as it would interface with actual system hardware on a non-virtualized machine. For example, guest OS 220 interfaces with virtual disk 240 and/or virtual memory 230 to access an executable guest application file. These interactions are transparently mapped by virtualization software to actual system hardware 100 that can provide the requested resources.
Virtualization software can include a Virtual Machine Monitor (VMM) 331 and a virtualization kernel 600. As used herein, the term “hypervisor” can refer to the VMM 331 alone, or the VMM 331 and the kernel 600 together. Device emulators 330 emulate the virtual system hardware components that are shown as part of VM 200.
Virtual machines can be configured as “fully virtualized,” in which no software components are included in the guest software 203 other than those that would be found in a non-virtualized computer. For example, the guest OS 220 could be a commercial, off-the-shelf OS with no components designed specifically to support a virtualized environment.
“Para-virtualized” machines can include guest software 203 that is configured in some way to provide features that facilitate virtualization. For example, a guest OS 220 that is specifically designed to avoid certain privileged instructions and certain memory address ranges can be part of a para-virtualized machine. In another example of para-virtualization, a driver may be loaded into the guest OS 220 that is designed to communicate with other virtualization components.
A virtualized computer system may be referred to as a “hosted” system when the virtualization software relies on system software that is separate from the virtualization software for certain functionality, such as for performing certain Input/Output (I/O) operations. For example, the virtualization software may rely on a separate, conventional host OS, installed directly on the system hardware, for providing such functionality. An example of a hosted virtualized computer system is the Workstation virtualization product made by VMware, Inc. of Palo Alto, Calif.
A “Non-Hosted” virtualized computer system is one in which the virtualization software does not rely on separate system software to provide such functionality. Instead, such functionality is implemented in the virtualization software itself. The virtualized computer system of FIG. 1 is a non-hosted virtualized computer system. In the system of FIG. 1, the VMM 331 may be tightly coupled with, or even part of, the kernel 600, which may be designed specifically to provide efficient support for executing VMs. An example of a non-hosted virtualized computer system is the ESX server virtualization product made by VMware, Inc of Palo Alto, Calif.
A virtual machine environment provides a convenient platform for the recording (logging) and replay of execution. Recording and replaying a virtual machine execution can be useful for debugging by allowing a developer to step through a recorded execution while reviewing the guest software state at each step to identify the cause of an error. For example, on replay, the developer can look at memory, set breakpoints, and single step through the execution to identify problems and resolve them.
Deterministic replay in a virtual machine creates an execution that is logically equivalent to an original execution of interest. Two executions are logically equivalent if they contain the same set of dynamic instructions, each dynamic instruction computes the same result in the two executions, and the two executions compute the same final state of the system (CPU, memory and devices). A deterministic replayer can be based on VMware's virtual machine monitor, which is a thin layer of software that sits between hardware and a guest OS to provide a virtualized IA-32 Instruction Set Architecture. Such a replayer supports full-system replay, that is, all data necessary for the execution of the entire virtual machine (VM), including a guest OS and guest applications, is recorded and replayed. During recording, all sources of non-determinism from outside the virtual machine are captured and recorded in a log file. These include data and timing of inputs from all devices, including virtual disks, virtual network interface cards (NIC), etc. A combination of techniques, such as device emulation and binary translation, are used to ensure deterministic replay as long as the recorded device input data are sent to guest software 203 at the right times.
It is known to use program checking tools in non-virtualized environments to facilitate the development of a software application. Print statements and software assertions can be included in an application's program source code that can help to test and assure otherwise unstated assumptions within the program. For example, the traditional assert( ) statement is a preprocessor macro defined by including assert.h in a C program. If the expression it contains evaluates false, assert( ) writes the expression, source filename and line number to standard error, then calls abort( ) to end the process and possibly create a memory image. If disabled by defining NDEBUG at compile time, assert( ) has no effect.
However, such assertions can disadvantageously introduce “probe effects” into the development process. When the application is executed, with assertions enabled, system resources are absorbed by the execution of the assertions themselves, which can throw off critical timing relationships in the application. This can introduce new bugs into the program, cause other bugs to be missed and mask still other errors. Once debugged, assertions are often removed from the application program. This again changes the application behavior and, even worse, makes the application much more difficult to debug because the automatic error detection provided by assertions are no longer available.